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Chapter I 


Introduction and Summary 

In thla report wa aummariza the progroaa raaultad from tha NASA 
Cooparatlva Agraamant NCCI-52 on tha aubject matter of "Nultilaval Semantic 
Analyala and Problam-Solvlng in the Flight Domain". Thla work ebyara tha 
period from July 11 » 1981 to July 10 » 1982. 

The overall goal of this project ia the conceptual development of 
a computer-based cockpit system which is capable of assisting the pilot in 
such important tasks as monitoring* diagnosis and trend analysis. The system 
is properly organized and is endowed with a knowledge base so that it enhances 
the pilot's control over the aircraft while simultaneously reduces his work~ 
load . 

The first phase of our work deals directly with the monitoring 
function. Based on a novel hierarchical levels model the monitoring function 
is achieved via the generation of a dynamic reference which is context-based. 

The planning algorithm produced a desirable plan at each level and details of 
the plans are generated as the propagation of the planning activity progressed 
top-down from the route level, passing through the trajectory level to reach 
the control level. Plan recovery activities will be needed whenever a change 
occurs in the context. Permissible changes Include weather, controller com- 
mands or system malfunctioning. Details of this work is summarized in Chapter 
II of this report. 

A second phase of our work is in the automatic diagnosis of system 
malfunctioning based on sensory data. Since system redundancy normally provides 
protection against single fault our work emphasizes the real-world problem of 
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diagnosis of multip Is- fault situations with fault mashing. With tha uss of 
flow modal analysis tha fault is isolatad to cartain aubaraas whata functional 
iBodala ara than uaad to daduca conaiatancy of aasumad fault pattarna. This 
phaaa of our work is diac^saad in datail in Chaptar III of this raport. 

Tha final phase of our work deals with tha rationalization of 
structures. This is needed for tha reasoning of mechanisms for tha purposes 
of diagnosis. One of the major weaknesses of present theory of diagnosis is 
its shallowness in understanding the functions of tha mechanism its intends 
to diagnose. A theoretical understanding of how mechanism work la a funda- 
mental precondition for intelligent deep-level diagnosis. 


Chapter II 
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TIm InttlllgaBt Monitor 


1. ItttrOdUQtiQD 

Xn thla paat year auoh progrtaa haa baan Mda on tha intalligant 
flight aonltor raaaaroh* Tha neat Inportant prograaa waa aada In tha 
davalopmant of tha oonoeptual lavala planning arohltaotui^a. Thin arohl- 
taotura la tha oulnlnatlon of tha work on tha aultl-iaval planning 
theory [1]* Tha conoaptual lavala planning arohltaotura la naoaaaai^ 
baoauaa intalligant oonltorlng raquiras aophlatloatad planning oapabil- 
Ity. 

The function of tha cooputar monitor is to oontlnuoualy obaarva the 
flight anvlronmant and avaluata the aituatlon for poaaibla errors that 
would threaten safety of the flight. The use of such an onboard com- 
puter monitor can significantly reduce the workload of the flight craw 
by relieving the crew of the tedious and repetitive task of scanning the 
numerous instrument readings for possible problems. The computer moni- 
tor would be especially useful during periods of high workload when the 
crew la busy. By assisting the crew in the monitoring taski the com- 
puter monitor enables the crew to devote more time to other time- 
critical tasks. Another advantage of the computer monitor is that the 
monitor would not be affected by typical human failings such as boredom i 
fatigue, or fixation. It is for these reasons that commercial flight 
crews recommended tha monitoring task for the intalligant onboard com- 
puter. 
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Monitorlnf th« aotivltlas of tho flight orow roquirts knowing what 
tha flight oraw ahould ba doing at aaoh point of tha flight. In othar 
Word«f tha nonitor raquiraa a rafaranoa of how tha world ahould ba in 
ordar to da tormina if tha world ia aa it ahould ba. Qanarating thio 
rafaranoa in a planning taak. It ia nooaaaary to andow tha monitor with 
tha knowladga of planning and axaoutlng tha flight, iutomatio planning 
in tha flight domain ia a formidabla taak. Firatl/r tha flight domain 
la a complax domain. Flight raquiraa tho knowladga of rout a planning* 
navigation* airoraft control* amarganoy prooadura* and airoraft aubaya- 
tama. The coordination of thaaa dlffarant knowladga la oomplloatad by 
tha fact that thay often interact with each other [2*3]. Secondly* the 
flight domain ia alao a dynamic domain. Eventa beyond tha control of 
tha flight oraw affect the flight. Weather condition nay change quickly 
and maohanloal aqulpmenta both on tha ground and on tha air may fail. 
Thua the carefully deviaed plan may be ruined by dynamic events. Any 
planner operating in the flight domain muat deal with the complexity of 
this domain. Tha conceptual levels planning architaotura is designed 
toward this goal. 

Tha oonoeptual levels architecture organizes the domain knowledge 
into conceptual levels. A conceptual level contains a subset of the 
domain knowledge and is related to other levels by the form/functlon and 
the precondition lnter«K -el relationships. The levels form a hierarchy 

t 

based on these inter-level relationships. Planning in the conceptual 
levels architecture consists of activities within a level and activities 
between the levels. Inter-level planning controls the intra-level 
planning at each level and together with the levels hierarchy provides 


the global viewpoint neoesi^ary to control the domain knowledge complex- 
ity. I 


Z. MotivateioB Xon ihft Canflaatual JLs:£fila. Theory, 

The intelligent monitor requires dynamic references for the many 
Variables of the flight domain. Those references are generated by the 
planner* Planning in the flight domain la a formidable task. Though 
much work has bean done in automatic planning i none of these works 
employ a domain as complicated as the flight domain. The planner in the 
flight domain must deal with the complexity in the horizontal direction 
as well as the complexity in the vertical direction. 

Horizontal complexity i® the sheer number of variables that must be 
considered. These variables range from the aerodynamic variables such 
as the angle of attack, the pitch angle, the climb rate, the velocity » 
to the subsystems variables such as the engine rpm, the fuel flow rate, 
the engine temperature, the bus switch setting, the fuel valve setting 
to the aerodynamic control variables such as the elevator setting, the 
aelleron setting, the landing gear control settings the flaps setting to 
the navigational variables such as the aircraft location, the aircraft 
altitude, the aircraft heading, the VOR frequency setting, and the refu- 
eling airport. The sheer number of variables makes it difficult for the 
planner to determine which variable should be considered next. 
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The flight domain is also complex in the deep (vertioal) sense* 
The flight domain has many facets that intf-'aot in an intrioate fashion* 
The aircraft climb rate is dependent on i'^e flap setting* the elevator 
setting* and the throttle setting* The throttle setting is implicitly 
dependent on the engine system. The engine system* in return* is depen- 
dent on the pitch angle and the elevator setting since the engine tem- 
perature is dependent on the pitch angle and the throttle setting. The 
variables have a tangled relationship with each other. These tangled 
relationships between the variables make it difficult for the planner to 
determine what la important at a given point of planning. 

Besides the domain complexity* the planner is must also deal with a 
dynamic domain. All the planning works thus far have dealt with static 
domains where the planner 1s the only agent that can change the world. 
This is not true in the flight domain. The flight domain Is inherently 
dynamic. The weather may deviate from the forcast unexpectedly. The 
crew may be slow in correcting errors or may actually deviate from the 
flight plan. Lastly* the aircraft itself may fail in some way, thus 
degrading the aircraft’s capability. The dynamic flight domain greatly 
complicates the planner’s task since a carefully planned plan may fail 
due to factors outside the planner's control. Thus the planner must b'i? 
able to initiate planning with incomplete Information and be able to 
correct plan failures caused by external events. 

Any planner operating in the flight domain must deal with the com- 
plexity of this domain. It is imperative that this complexity be con- 
trolled. The conceptual levels planning architecture is designed toward 
this goal. The conceptual levels architecture is a refinement of the 
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previous aulti«*level srohlbeobure* Ib is also bhe d^jao^ndenb of bhe 
hierarohloaX planner C^,5y6|7i83« 


!• Ihfi. .CQQQfiPbual iiiax^ Ihfiiicz 

The Qonoepbual levels approach is a semantio approach bo obbalning 
higher-level planning direcblon. The oonoepbual levels approach is des- 
cended from bhe hierarchical planning approach. The hieranohioal 
planner plans absbraobly using simplified model of bhe domain. Ib 
bhen gradually fills in bhe less Imporbanb deballs. The oonoepbual lev- 
els planner augments bhls deflnlblon in bhab bhe hierarchy is nob based 
on bhe amounb of bhe de balls bub rabher bhe kinds of debails. Insbead 
of bhe less debails of bhe absbraoblon space > bhe conoepbual levels con- 
bains differenb kinds of knowledge. In bhe oonoepbual levels hierarchy, 
bhe semanbios change as well as bhe amounb of debail. 

The oonoepbual levels approach organiises the domain knowledge inbo 
levels. Planning is done within a level and between levels. The levels 
partition the domain knowledge into smaller partitions, but the parti- 
tions (levels) also relate bo each other teleologically. The levels 
also form a levels hierarchy. The relationships between two levels can 
be either the form/function relationship or the precondition relation- 
ship. These inter-level relationships form bhe basis for higher-level 
viewpoint. 
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1«1* Illfi. CfiiJijSAl, Framework 

The planner operates in a world of causal relations. The variables 
in the world are related to each other through these oausal relations. 
The planner examines these causal relations to generate actions that 
will maneuver the goal variables to the desired state. The conceptual 
levels arohiteoturo is motivated by the oausal framework observation. 
The causal framework observation is that the variables of a domain do 
not relate to each other with the same intensity. In other words, some 
variables are more closely related than others; some variables are 
tightly related while others are loosely related. A oausal framework is 
a group of tightly related variables and the causal relationships 
between these variables. Figure 1 illustrates the causal framework 
organization of the domain variables. 

A conceptual level is associated with a causality framework. Dy 
decomposing the domain into causality frameworks, the domain 1s simpli- 
fied into nearly Independent subdomains. A conceptual level is more 
than a group of variables and oausal relations. A conceptual level is a 
planner, a representation, and the knowledge to communicate with other 
conceptual levels. The conceptual levels form a hierarchy that defines 
the first out of problem decomposition and defines the relationships 
between the subproblems. The conceptual levels hierarchy defines the 
nearly Independent subproblems and how they interact with each other at 
the interface. Besides functioning as a means of controlling complex- 
ity, the hierarchy also structures the knowledge base. Each level has 
its own knowedge base of flight knowledge and the knowledge of 
interacting with other levels. 





Ihfi. Lfly-flla 


The flight domain knowledge Is presently organized Into four con- 
ceptual levels: the route level, the trajectory level, the flight-, 

'll, 

control level, and the aircraft subsystems level. Figure 2 Illustrates 
the hierarchy. The route level, the trajeot4''y level, and the fight- 
control level form a form/ function hieratbhy with the route level at the 
top and the flight-control level at the bottom. The form/funotion rela- 
tionship between two levels Is such that a complete plan at the top 
level (the form level) can be Implemented at the bottom level (the func- 
tion level) with the variables from the bottom level. An example of the 
form/funotlon relationship Is that a computer register Is Implemented by 
flip-flops which are l,mplemented by logical gates which are Implemented 
by electronic circuits. Another example Is that an aircraft route Is 
implemented by a trajectory which is in turn implemented by a sequence 
of flight control settings. The second kind of Inter-level relationship 
is the precondition relationship. Here, Instead of implementing the 
upper level, the lower level enables or supports the upper level. An 
example of this relationship is that the power supply enables the 
electrical circuits to function and indirectly enables the registers to 
function. Another example is that the engine system enables the throt- 
tle to be effectives The electrical system also enables navigation 
which makes the flight controls settings sensible. The subsystems level 
supports the flight-control level. The subsystems level also supports 
the trajectory level (for navigation). 








liifi. .Rouiift imsX 
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The route level Is the highest level in the oonoeptual level 
hierarchy (combined form/funotlon and precondition hierarchy). The 
route level is the highest level because it is the most abstract level 
and because it has the broadest viewpoint over the plan. The route 
level is responsible for planning a route from the origin airport to the 
destination airport. The route is a sequence of airway segments. An 
airway segment is a segment between two navaids, typically a vortac or a 
non-dlreotional beacon. Since it is common to have a navald near an 
airport I the route segment can also terminate at an airport. 

At the route level the world is abstracted to a network of nodes 
and links. The nodes represent the airports and navalds and the links 
represent the airway segment between the two nodes. Other information 
are associated with these nodes and links. Examples are the avlailabll- 
ity of the airport and the airway segments » the refueling capability of 
the airport and the runway length, the adverse weather position and 
velocity, and the minimum enroute altitude of the airway segments. The 
knowledge base also contains knowledge of the aircraft such as the air- 
craft airspeed, the aircraft service ceiling, and the aircraft range. 

The route level also contains the active knowledge necessary to 
generate the route. Planning at the route level is essentially a con- 
straint satisfaction problem. A plan is a sequence of airway segments 
that leads to the destination. Besides achieving the goal, the route 
must satisfy a host of constraints. These constraints can be stated as 
the preservation of the aircraft integrity, adherence to the FAA regula- 


tlon, and the minimal expenditure of fuel and time. These basic con- 
straints oan be decomposed to other constraints. For example, minimal 
fuel expenditure can be expanded Into short route, low power setting, 
best altitude, and no loitering constraints. Given this formulation the 
route-level planning Is based on a constraint-guided search. The search 
Is first guided by the more Inflexible constraints to obtain plausable 
planning Islands. Then more flexible constraints are applied to connect 
these planning Islands. 

The route level generi^tes a route consisting of a squence of airway 
segments. Figure 3 gives an Illustration of the planning at the route 
level. This route Is passed to the lower levels. Besides the route, 
there Is another bidirectional Interface with the lower levels consist- 
ing of the aircraft performance variables such as the airspeed, service 
celling, and the range. If values of these Interface variables are 
unacceptable to the lower levels, replanning at the route level will be 
necessary. 


!.£.£. Ihs. Tra.IeatQrv Level 

The trajectory level Is the conceptual level below the route level. 
The trajectory level generates a 3-dlmenslonal flight trajectory that 
extends to the destination. In order to plan its plan, the trajectory- 
level planner needs direction from the route level. A completed route- 
level plan is passed to the trajectory level with the proper semantic 
transformation. A semantic transformation is sometimes necessary for 
communication between levels because the levels may use different 
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vocabulary. Figure 4 illusbratee the transition from the route~level 
plan to the trajectory-level goals. 

The trajectory level is below the route level in the conceptual 
level hierarchy because it depends upon the route generated by the route 
level. It requires the route produced by the route level to generate 
the actual trajectory goal. The route guides the planning at the tra- 
jectory. The route is the goal of the trajectory and the trajectory 
implements the route. 

A flight segment is defined to be the takeoff airport, the 
sequence of airway segment between the takeoff airport and the landing 
airport, and the landing airport. The trajectory level divides a flight 
segment into three phases: the takeoff phase, the cruise phase, and the 
landing phase. The trajectory level generates the trajectory for each 
phase. For the cruise phase, the horizontal trajectory corresponds to 
the route. The aircraft performance knowledge base is an Integral part 
of the trajectory level. Given the route and the goals of the aircraft 
airspeed, service ceiling, and range from the route level, the trajec- 
tory level checks the aircraft performance knowledge base to see if 
this can be accomplished. If this can not be done, the trajectory level 
suggests revisions to the route level and the route level will replan 
and generate another set of goals for the trajectory level. 

For the instrument flight, the FAA has established required takeoff 
and landing trajectory for many airports [9,10]. The trajectory level 
uses these established trajectories as the trajectory goals for the 
takeoff phase and the landing phase. These trajectories are stored in 
the trajectory knowledge base and are retrieved as keyed by the route. 
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Figure 5 shows the mapping from the trajectory goals to the trajectory 
plan. 

Another aspect of the trajectory level is navigation. The trajec- 
tory goals are the desired path of the aircraft. It specifies where the 
aircraft should be. It takes navigation to determines the aircraft 
location with respect to the desired aircraft flight path. It is also 
the responsibility of the trajectory level to determine the aircraft’s 
location and the oorreotlon trajectory to rejoin the desired flight path 
should the aircraft wanders off the desired flight path. 

1.2.1. Ihs. night. .Cflntrfll. Lay.el 

The flight control level is the conceptual level below the trajec- 
tory level. The flight control level 1s responsible for generating the 
plan to maneuver the flight controls to achieve a certain trajectory 
goal. The flight controls are the throttle, the fuel air mixture, the 
aeileron, the stabilator, the rudder, the flaps, and the landing gear. 
The aircraft is assumed to be the Piper Cherokee, a light, single 
engined aircraft. Larger commercial aircrafts have other additional 
flight controls. The trajectory goal is given by the trajectory level. 
The plan at the flight control level is a sequence of the flight control 
settings that achieves the given trajectory goal. 

The flight control level is concerned with the aerodynamic 
knowledge. The aerodynamic knowledge include the forces that influences 
the flight trajectory. The aerodynamic knowledge base also includes the 
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Figure 5 Planning at the trajectory level 
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aseooiafcioii between the night controls and theae forces. For example, 
the throttle is associated with the force of thrust, and for a given 
aircraft attitude, greater thrust results in greater climb rate. The 
stabilator controls the pitch attitude which in turn controls the 
airspeed. The flap increases the lift coefficient, thus enabling flight 
at lower airspeed. However, the flap also increases the drag coeffi** 
cient, thus requiring more power to fly at lower airspeed. These are 
examples of the knowledge at the flight control level. The variables at 
the flight control level are tightly connected and interacting. Thus 
they form a causality framework. Figure 6 shows the mapping from the 
flight control level goals to the flight control level plan. 


gubayatema, 

The aircraft subsystems level is the conceptual level below both 
the trajectory level and the flight control level. The aircraft subsys- 
tems level performs the support role for both the trajectory level and 
the flight control level, The subsystems level generates plan to sus- 
tain the trajectory level by providing an uninterrupted electrical power 
to the navigational equipment. The subsystems level also generates plan 
to sustain the flight control level by ensuring a running engine. These 
are the subsystems support for our example aircradi't, the Piper 
Cherokee. Larger commercial aircrafts would also have hydraulic and 
pneumatic support subsystems. 

The relationship between the aircraft subsystems level and the two 
conceptual levels above it is an enablement relationship. This 




Zl 


tnablenenfc relationship is different fron the forn/funotion relationship 
between the other oonoeptual levels. In the forn/funotion relationship! 
the form at the top level is implemented by the funotions of the bottom 
level. In the enablement relationship! the bottom level enables the top 
level to aohieve the top level's goal. For example! the planner oan 
not navigate without powered navigational equipment* The proper throt- 
tle setting is useless if the engine died of fuel starvation. 

The causality framework; at the subsystems level is that of meohani- 
oal systems suoh as the eleotrioal system and the fuel system. These 
systems are interacting. The eleotrioal system powers the eleotrioal 
fuel pump whioh sustains the engine. The engine then I'rives the alter- 
nator which powers the eleotrioal system. A representation such as the 
Common Sense Algorithm oan be designed to represent these meohanioal 
systems til! 12! 13], Figure 7 illustrates the Common Sense Algorithm 
representation. 

1.3L. .Ihs. Iab.sr.-la.vfll P,.eR.Qnd.QnQifli3. 

The onusal framework determines the conceptual levels! and the 
planner at each level only has to consider the variables within the 
causal fraaewcrk. This is beoause the variables within the causal 
framework are tightly related. The intra-level planning may include any 
of the planning techniques developed thus far, and possibly a recursive 
application of the levels architecture. The interesting feature of the 
oonoeptual levels planning architecture, however, is the inter-level 
relationships or dependencies. 
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The previous sooblon hms already diaouased In sone detail the 
form/funotion and the preoonditlon i«ter«*levol relatlonahlpa. Both of 
these relationships are top-down In the sense that the top level $lves 
the bottom level direction and guidance. Thus the direction of planning 
Is top-down because the top level provides the necessary higher-level 
direction. Planning at the trajectory level first before planning at 
the route level would be In vain because the trajectory Is probably in 
the wrong direction since the refueling airport has yet to be deter- 

I 

mined. | 

The inter-level dependency also operates In the bottora-up direo- I 

tloni though this Is less obvious. In the case of the precondition I 

Inter-level relationship, the bottom level depends on the top level for I 

the goal speoifioation, but the top level also depends on the bottom I 

level for the top-level operator capability. For example, the flight- f 

control plan is void if the subsystems level Can not keep the engine 
running. This kind of dependency continues in the form/f unction hierar- 
chy in the bottom-up direction. This is because the upper level plan 
step is implicitly dependent on the lower level plan segment. The upper 
level plan step is implemented by a lower level plan segment, thus if 
the lower level plan segment can not deliver the expected result, then 
the upper plan step is invalid, thus Invalidating the upper level plan. | 

The result of this bottora-up dependency is that the operator capa- 
bilities of the upper level depend on the lower level. Thus the opera- 
tor capabilities at the upper level may change due to changes at the 
lower levels. For example, suppose consistent plans have been completed 
at all four levels. Then the engine runs hot and the subsystems planner 


wants to out power by This reduces the throttle setting at the 
flight-control level, which reduces the airspeed and the altitude cell- 
ing at the trajectory level, which Invalidates an airway segment at the 
route level because there Is a mountain under the airway segment. !I!hus 
a change at the lowest level affects even the highest level. 


3..1. IntfiH-Ifiyfil iSfifflaatlQ. Iranarorfflatlon, 

since the Inter-level dependencies run both up and down the concep- 
tual levels hierarchy, the levels must communicate with each other. 
Communication Is nob straightforward since, by design, the levels do not 
have to speak with the same vocabulary. In the top-down direction, the 
upper level specifies the goal for the lower level. A completed plan at 
the upper level becomes the lower level's goal. Semantic transformation 
is necessary to make the demand comprehensible. The same Is true In the 
reverse direction. The lower level specifies the upper level's operator 
capability. A dead engine at the subsystems level Is translated to 
effectively zero throttle capability at the flight-control level and 
then zero climb rate capability at the trajectory level, etc. Thus, 
semantic transformation knowledge base is necessary at each level for 
communication In both directions. 


l.l. L- SY filfl, fumoany. 


The oonoeptual levels planrxlng arohlteoture is a semantic parti- 
tioning and organijsation of the domain knowledge. The partitioning 
divides the domain world into smaller fiefdoms. The planner within a 
partition can concentrate on its own fief and Ignore the rest of the 
world. The organization specifies the relationships between the fiefs 
and makes the partitions meaningful. A random partitioning is senseless 
because it has no organization. 

A unique feature of the conceptual levels architecture is that 
there is planning consistency within a level and there is also planning 
consistency over the levels hierarchy. The planner in each level makes 
sure the plan within each level is true with respect to the factors 
inside the level. The plan within each level is also true to the fac- 
tors outside each level. This is accomplished by inter-level communica- 
tion. Planning direction is passed from the top down. Operator capa- 
bility is passed from the bottom up. Thus the planner considers not 
only the factors within its own level directly i but it also considers 
the factors outside its level in a more indirect fashion. 

Unlike previous planning systems, the conceptual levels architec- 
ture defines uniform levels of domain semantics. The plans at each 
level all makes sense with respect to their own level (context). Thus a 
complete plan at each level can be constructed, and a complete plan over 
the levels hierarchy consists of a complete plan st each level and the 
plans are consistent with each other. 

The uniform levels of domain semantics definition enables the 
focusing of attention. The planner within a level can almost ignore the 
rest of the world. The levels hierarchy also specifies where to focus 
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the attention next* This Is covered In more detail In the following 
section. The nearly independent levels can also support different 
knowledge representation at each level. Since knowledge representation 
should be fitted to the need and since the level semantics may be dif- 
ferent i there can be a mixture of knowledge representations in the lev- 
els hierarchy. 

The form/function and precondition inter-level dependencies allcw 
the vertical decomposition of a task. The divide-and-conquer paradigm 
advocates the decomposition of a task. However f in actual usage, the 
divide-and-conquer paradigm provides the horizontal subtask decompos- 
tion, or sub tasks of similar semantics. The conceptual levels hierarchy 
specifies the vertical subtask decomposition where the vertical decompo- 
sition indicates the subtasks’ semantics are different across the 
form/ function or precondition dependencies. These inter-level dependen- 
cies also enables higher-level planning direction. Plan consistency 
over the entire hierarchy starts at the top level. When the top-level 
plan is completed, it is passed downward as the goal for the lower 
level, etc. 

The conceptual levels hierarchy also enables partial planning where 
planning does not have to proceed down to the last detail. For example, 
as long as the route level and the trajectory level have satisfactory 
plans and the subsystems level can provide the support, the planning at 
the flight-control level can be mostly ignored except for the immediate 
future. 

The conceptual levels hierarchy provides the theoretical foundation 
for a new approach to planning. The hierarchy alone, however, is not a 


planning system. In addition to the hierarchy » a planning control 
mechanism is required. the planning control mechanism for the levels 
architecture will be covered in the next section. 


iL< IhfiL Planning Control Mechanism 

The conceptual levels hierarchy specifies complex relationships 
within and without a level. Such complex relationships require a 
sophisticated planning control mechanism. Planning activities in the 
conceptual levels hierarchy can be broken down to intra-level planning 
activities and inter-level planning activities. 


iRtra-leycl Planning 

The intra-level activities consist of the plan generation prpcess 
once the goal is given. Of course, in this case, the goals are obtained 
through the inter-level planning activities. The intra-level planning 
activities occur inside a conceptual level. Within the route level, the 
intra-level planning process generates a route from the origin airport 
to the destination airport that satisfies the constraints applicable to 
the route. Within the trajectory level, the intra-level planning pro- 
cess generates a trajectory that implements the route and also satisfy 
the applicable trajectory constraints such as controlled airspace and 
the aircraft performance limitations. When the trajectory is worked 
out, the flight control level planner plans the control actions that 



will achieve the desired trajectory. 

The intra-level planning activities generates the plan at a partic- 
ular conceptual level. Because of the conceptual levels architecture, 
the planner at a given level only has to consider the variables at that 
particular level. Thus the size of the problem is reduced from the 
entire flight domain to the size of that conceptual level. This reduc- 
tion is the power of the architecture. 

While the intra-level planner has only to examine a subset of the 
domain, someone else has to make sure the total picture is coherent and 
consistent. Some mechanism has to maintain the overall viewpoint to 
make sure all the subplans add up to a functional total plan. This is 
the responsibility of the inter-level plan control mechanism. While the 
conceptual levels architecture enables decomposition, the inter-level 
plan control mechanism enables the integration of the pieces. 


i.2. Planning 

The inter-level controls can be classified into two aspects; focus- 
ing on a level and transitioning the levels interface. Transitioning 
the levels interface is not interesting; it is merely shifting the focus 
up or down one level. However, the reason for the focus shift is 
interesting. Focus means the narrowing of the scope. Focussing the 
attention has meant in previous works the current locus of planning 
activities. For example, the planner may be searching for the operators 
that can achieve a goal or the planner may be contemplating the decompo- 
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sltlon of a goal. If the planner goea to another part of the plan to 
oontemplate other problema» the planner la aald to have changed ltd 
fooua. The foouaalng of attention In the context of the conceptual lev-* 
ela architecture has a different meaning. In thla context, foouaalng 
meana limiting the acope to a conceptual level. In the conceptual lev- 
ela architecture, the fooua ahlfta frequently aa the Inter-level plan 
control mechanism enforces ooh<i>renoe over the entire hierarchy. 

The Inter-level planning control mechanism has precedence over the 
Intra-level planners and controls the Intra-level planners. The inter- 

/i 

level planning control mechanism is rooted In the inter-level relation- 
ships. The form/funotion Inter-level relationship results in both tt>y- 
down and bottom-up control actions. The precondition Inter-level rela- 
tionship results in bottom-up control actions. 

Control proceeds top-down when a plan In the top level is passed to 
the lower level as the desired goal. For example, when the plan at the 
route level Is completed, the route is passed to the trajectory level aa 

I 

the trajectory level goals. Then the focus is shifted to the trajectory 
level as the trajectory level planner plans to achieve the route. Con- 
trol also flows bottom-up because the lower-level defines the top-level 
operator capabilities. For example, if the subsystems level can not 
maintains engine operation, then the operators at the flight control 
level become Invalid. Thus If changes occur at the lower level, the 
focus will shift to the upper level to verify that the upper-level plan 
is still veilid. , 

The reasons for making a focus shift can be due to the PROPAGATE- 
VALUE-UP, the PROPAGATE-PLAN-BOWN , the PROPAGATE- VALUE-REQUEST-DOWN, and 
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the PROP AGATE-GOAL-REQUEST-UP actions. The PROPAGATE- VALUE-UP action is 
utied to Qommunioate to the upper level its operator capabilities. The 
PROPAGATE-PLAN-DOWN is used when the upper level has completed its plan 
and wishes to pass it down as the goal for the lower level. The 
PROPAGATE-VALUE-REQUEST-DOWN action is used when the upper level 
requests a clarification of its operator capabilities. The PROPAGATE- 
GOAL-REQUEST-UP action is used when a lower level requests a clarifica- 
tion of its goals from the upper level. 

When attention is first focused on a level, the control mechanism 
needs to determine what needs to be done, or what caused the focusing of 
attention on this level? There are many possible causes to the focusing 
of attention on a level. Whatever the causes, the main actions at a 
level are propagating a message, plan at that level, and recovery plan 
at that level. Plan at that level results in the PLAN action which 
calls the planner for that level. PLAN can be described as: 

IF (NOT HAS GOAL) THEN PROPAGATE-GOAL-REQUEST-UP 
IF (NOT HAS OPERATORS) THEN PROP AGATE- VALUE-REQUEST-DOWN 
CALL PLANNER 

Recovery plan at that level results in the action RECOVERY-PLAN which 
differs from PLAN in that RECOVERY-PLAN remedies small perturbations. 
RECOVERY-PLAN can be described as; 

LOCATE-PERTURBATION 

PLAN 

PATCH-PLAN 
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The aotlor. taken when first fooused on a level depends on the cause 
of shifting the focus to that level. If the oause is because a value is 
requested from above, the action is: 


IF (VAI.UES REQUESTED) THEN 
IF (HAS VALUE) THEN PROP AG ATE- VALUE-UP 

ELSE PROPAGATE- VA1.UE-UP( PROPAGATE- VALUE-REQUEST-DOWN) 


The other aotlons are: 


IF (GOAL REQUESTED) THEN 
PLAN 

PROGAPAGE-PLAN-DOWN 


IF (SUPPORT VARIABLES CHANGED) THEN 
RECOVERY-PLAN 
PROPAGATE-VALUE-UP 
PROPAGATE-PLAN-DOWN 


IF (PLAN DEVIATION OCCURRED) THEN 
RECOVERY-PLAN 
PROPAGATE-VALUE-UP 
PROPAGATE-PLAN-DOWN 


IF (NEW GOAL OR ADJUSTED GOAL) THEN 
PLAN 

PROPAGATE-PLAN-DOWN 


In addition to these inter- level actions, there are also three 
other aotlons that starts the ball rolling. The START- AT- THE'-TOP-LEVEL 
action starts the planning at the top level in the beginning. The 
LOCATE-LEVEL action locates the appropriate level for repair work when 
either a support has changed or when the aircraft has drifted away from 
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the original plan. The ORDER-BX-PRIORITT action determines the priority 
when several disturbances require attention. 

The above actions describe the planning control actions necessary 
to support planning over the conceptual levels planning architecture. 
The focus of this planning control mechanism research is on the aotlvi*’ 
tles due to inter-level relationships. 


Sunmary 

The conceptual levels planning architecture is unique because it 
uses the semantic organization of the domain knowledge to achieve 
higher-level planning direction. This approach is motivated by the 
causal framework observation that some variables are more tightly 
related than others. A tightly related group of variables forms a con- 
ceptual level, A planner within the level plans directly with the fac- 
tors within the level and indirectly with factors outside the level. 
The factors from outside the level arrive via inter-level messages. 
Semantic transformation may be necessary to communicate across the level 
boundaries. 

The inter-level planning control mechanism has precedence over the 
intra-level planners and controls the intra-level planners. The inter- 
level planning control mechanism is rooted in the inter-level relation- 
ships. The form/ function and precondition inter-level relationships 
give the levels architecture its power. These two kinds of inter-level 
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relationship enable the high-level planning that guldea the lower-level 
planning. The organization of domain knowledge by the form/funotlon and 
the precondition relationships coupled with the levels planning control 
mechanism give the oonoe|)tual levels architecture Its power. 

The conceptual levels architecture enables the focusing of atten- 
tion on a small portion of the domain and the focusing of attention on a 
level of the planning process. The levels hierarchy also enables the 
vertical decomposition of a task because the hierarchy enables a verti- 
cal definition of the domain semantics. The levels architecture pro- 
vides higher-level planning direction since the completed higher-level 
plan becomes the goal for the lower level. The levels architecture sup- 
ports non-homogenous knowledge representation. This Is because planning 
at each level is buffered. Lastly, the levels architecture enables par- 
tial planning. Again, this falls out from the vertical definition of 
domain semantics. 

The work accomplished thus far consists of the design of a semanti- 
cally oriented planning architecture. Previous approaches to complex- 
ity control have been more syntactically oriented than semantically 
oriented. The conceptual levels approach organizes the domain knowledge 
into levels that eu'e based on the form/function and the precondition 
inter-level relationships. This architecture has been applied to the 
aircraft flight domain and a walk-through scenario is easily con- 
structed. Lastly, an initial design of the inter-level planning-control 
mechanism has been done. This mechanism performs meta-planning in the 


levels context. 
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Chapter lit 
Model-Based Diagnosis 


X* Overview 

During the past year, our research is fooused on finding a suit- 
able way to model the aircraft mechanism to provide the knowledge base 
for the rationalization of failure possibilities. 

Our previous research [1] has resulted in a verification method 
for "given” failure assertions. With this method, a fault-asserted 
mechanism is viewed as a "new" mechanism. The verification process is 
proceeded in following two phases; model-reconstruction and 
measurement-propagation. In the first phase, the constraint model for 
the failure-asserted mechanism is established by modifying the con- 
straint descriptions of fault-asserted oomponent(s) . In the second 
phase, we use the new constraint model to analyze sensory measure- 
ments. The specific technique involved is called "constraint propaga- 
tion" which has also been addressed by other artificial intelligence 
researches [2,3,^ 3. Our contributions are on the generalization of 
qualitative modelings and their interpretations which enables us to 
describe some quantitatively Imprecise, yet useful, engineering 
knowledge. The result of constraint analysis can be one of following 
two oases; (1) sensory measurements are propagated through the new 
constraint model without any conflict, or (2) at least one conflict is 
detected during the propagation process. In the former case, the 
underlying failure assertion is accepted as a possibility, and is Jus- 
tified by a set of inferred parameters. In the later case, the 
failure assertion is rejected since it fails to consistently explain 
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all aensory mtasureoentB* li 

With the eatabllahnent of verification prooeaa, we can objec- 
tively evaluate a heurlatically-infered failure asaertion* To com- 
plete our theory of dlagnoaia, we need to develop a reaaoning prooeaa 
to infer from the mechanism model a set of failure hypotheaea by Which 
deviated measurementa can be explained. This report diaouaaes reaulta 
summarized from our research on this direction, which includes follow- 
ing topics: (1) how to model the functional behavior of the mechanism, 
and (2) how to reason with the meohaniam model to assert failure 
hypotheses. 

2., Related Works 

Existent artificial intelligence works in the area of diagnoses 
are based on two basic approaches: the production-rule-based expert 
approach and the meohanlsm-model-based approach. Although intended 
domains of these researches may not be exactly airplane mechanisms, we 
will discuss problems involved in generalizations of these approaches 
to our domain of interest. 

2.»1> SulSriiRSSSi UXBfillt. AD££^AOh. 

The production-system paradigm [5] has been implemented for 
various applications; MYCIN [6] for medical diagnoses, PROSPECTOR 
[7] for mineral exploration, SACON [8] for structural analysis, and 
SU/X [9] for signal interpretation. Although none of above works 
are directly addressed to mechanism diagnoses, its basic scheme, as 


0 

provided by EMYCIN ElOl, can be readily applied fco build a rule- 
baaed oechaniam diagnosis system. Following such rule-based 
approaoh, however^ tbe oomputer knowledge baae encodes nothing but 
diagnostic rules resulted from human-experts' interpretations of 
their mechanism understandings. Since the computer Itself has no 
understanding of the objective mechanism, any modification of rules 
requires intervention of human experts [11]. 

The weakness of rule-based approach thus is clear; the experi- 
ence gained from building an expert system for a specific mechanism 
is "wasted" in the sense that it can not be transferred into another 
mechanism in the same domain. The remedy requires a fundamentally 
different approach to build a diagnosis expert system. The computer 
is programmed to use its understanding models of the mechanism, as 
encoded in the knowledge base, to perform diagnoses. Following such 
approach, the experience accumulated from building models for a 
specific mechanism can help to build diagnosis system for other 
mechanism in the same domain. Next, we will discuss tro instances of 
diagnosis systems based on such model-based approach. 

Model-based Diagnosis App ro aoh 

In the area of model-based diagnoses, we discuss tvfo MIT works 
based on rather different modeling schemes. In the first Instance, 

Brown demonstrate? that troubleshootings can be based on the 
hierarchical design-plan of a radio receiver. Thus, the knowledge 
base encodes "global" understandings of a mechanism. In the second 
Instance, deKleer use only the constraint model at component level 


to perform diagnoses on eleobronio oirouiba. Any use of "teleology" 
(or global knowledge) about the meohanlsm Is explicitly excluded* 

WATSON [123 is a computer program bo perform troubleshootings 
on radio-receivers. Brown’s diagnosis strategy is to backtrace 
faulty outputs among "stages" as defined by the hierarchical 
design-plan of a radio-receiver. The objective is to localize a 
possible faulty component with least measurements. 

WATSON’S diagnosis strategy is not applicable to our 

monitoring-diagnosis tasks for two basic reasons; 

(1) WATSON'S intended environments allow selections of test-points, 

injections of experimental signals, and physical separations of 
components. All these "diagnosis-initiated" requests are not 
permitted in our the airplane environment where only informa- 
tion available are measurements from pre-installed sensors. 
Brown’s assumed enviornments make it unnecessary for the troub- 
leshooting strategy to involve in complicated parallel 

hypothesis generations and evaluations which are essential for 
diagnoses in our airplane environments. 

(2) Brown’s mechanism model is based on the original design-plan 
which does not always meet implicit assumptions for his 
causality-based diagnosis strategy. A better alternative will 
be to develop a consistent modeling scheme which can result in 
a mechanism model suitable for diagnosis reasoning. We will 
further pursuit this subject later in the discussion of our 
approach. 
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Xn hla work for localizing faults in eleobronio oircuiba 
doKleer pursuits a purely looal method for diagnosis. Constraint 
models for oircuit oomponents are explioitly linked together by the 
oiroulb topology to form the model for the overall oircuit. Given 
measurements are propagated through the constraint model of the cir- 
cuit to deduce new parametrical information. The diagnostic stra- 
tegy is based on "coincidence’’ which occurs when one circuit parame- 
ter can be deduced in several different ways. When a contradiction 
is detected at a coincidence, deKleer's program looks back to all 
components involved in the deduction of that parameter and logically 
infers a set of possibly faulted components. 

The major weakness of deKleer’s looal approach lies in its ina- 
bility to incorporate global understanding of the circuit. More 
specifically, it fails to utilize normal measurements of a no-fault 
mechanism as an important information source for diagnoses. Also, 
the lack of knowledge on the functional structure of the mechanism 
severely limits its ability to propagate, thus to use, given data. 
Our theory, as discussed below, will show that by resorting to the 
global functional understanding of a mechanism, we can make better 
use of given measurements. 

1. £iur: Ciagnosla. .Ap.Dr.fla.oii 

Our theory of diagnosis is based on a "hypothesization- 
verification" paradigm which has also adopted by many other artificial 
intelligence systems Cl 4, 153. For mechanism diagnoses, the challeng- 
ing issue is to implement such paradigm baaed on models of the 
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meohanism. Other model-based approaches are based their diagnosis 
strategies on a single perspective of the mechanism (such as Brown’s 
using of design-plan model and deKleer's using of constraint model) 
which often fall to take full advantage of measurements available. Our 
approach first assumes that there are more than one point of view to 
model a mechanism. Our previous research results In a verification 
theory based on the constraint model which describes the mechanism 
from a analytical point of view. We now discuss our progress in 
another direction, namely, the modeling of meohanism from a functional 
point of view and the use of such model to rationalize failure asser- 
tions. 

1.1. liifi. Made! 

In contrast to an analytical perspective which views the 
behavior of a mechanism as an equilibrium state satisfying all con- 
straints of its components, the functional perspective recognizes 
that there are Interactions among components. 

We characterize the •'interaction'’ between two components as a 
flow of certain "medium" which can be "fluid" type (such as fuel, 
oil), or "energy" type (such as heat, electricity, or torque). 
Based on such "flow" interpretation, we build up the functional 
description of the mechanism at component level, namely, components 
are acting as basic functional units which "receive" and "deliver" 
flows . 

As an example in figure 1, a fuel-delivery mechanism driven 
electrically is pumping fuel to the engine. The flow description 
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identifies all the meaningful flow interactions among components of 
the mechanism t as shown in figure 2. 

iT 

In following seotions, wo discuss the concept of "subsystem 
whioh we Impose on the basic flow description of the mechanism. 
Then causalities among subsystem are studied, which results in the 

i) 

causal-dependency description of a mechanism* 

3.*1*JL> Ihs. Subayatema. 

Iha. £a.Y.elgpaeat, gX ^bay.aJi£m .CQivQ^p.t, 

Based on what a functional unit does with its flows, we 
further classify functional components into two categories; for 
those who merely "pass" or "consume" a particular medium flow, 
we call them "passive" (as analogous to "passive components" in 
electronic circuits), and for these who either "generate" flows 
or "convert" one medium flow bo the other, we call them "active" 
(again, analogous bo "active components" in electronic cir- 
cuits). For example, in figure 2, the component "electrical 
source" is active component whioh "generates" electrical flow, 
so is "fuel pump" whioh "converts" electrical flow into "fuel 
flow". L1 , filter, t2, and nozzle are passive because they 
either pass fuel flows or consumes fuel flow. 

Now we impose a functional organization on top of the basic 
flow description based on the identifications of active func- 
tional units. We group an active component with the set of pas- 
sive components which are "driven" by the generated medium flow, 
and call the whole functional group a "subsystem". As shown in 










figure 3> we group the fuel-delivery meohanlsm In two subsys- 
temSf called electrical subsystem and fuel subsystem respec- 
tively. 

We thus identify two essential actions underlying a subsys- 
tem concept: •’driving" and "response". "Driving" is initiated 
by the active component which under proper enablement create a 
tendency to cause medium flows among passive components of the 
subsystem. "Response" is the medium flow in the environment of 
passive components resulting from the driving action. Within 
the environment of response, variables (or functional' parame- 
ters) which eharasterize medium flows among passive components 
are associated with a set of physical laws related to the phy- 
sics nature of the medium involved. 

For example in the fuel subsystem of figure 3» the running 
of fuel pump with the fuel supply of a non-empty fuel pump 
creates a driving tendency to cause fuel flow in the environment 
formed by its passive components, namely LI, filter, L2, nozzle, 
and engine. The variables P’s and F’s characterize the fuel flow 
among the environment, which are governed by the laws of fluid- 
dynamics . 

Frame. Representation Ion .gubsza.tems. 

A frame-like representation [16] is chosen to provide 
"slots" for the description of knowledge surrounding a subsys- 
tem. Each essential aspect of a particular subsystem is to be 
filled under its corresponding slot, as listed below. Since all 
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physical components grouped under a subsystem are explioitly 
accounted for and assigned to their functional roles i the sub- 
system frame serves as a conceptual linkage between the physical 
structure and the functional description of a meohanlsm. 

(1) MEDIUM - 

The type of medium which underlies functional interactions 
among components of this subsystem. Components within a 
subsystem encounter a complete cycle of the medium, from 
its source/genoration to its drain/consumption. 

(2) DRIVER - 

The component Identified as the "driver" (or active com- 
ponent). Under proper enablement, as to be specified 
within this slob, the driving action causes medium flows 
among "passive" components, as specified by the environment 
slot, of the subsystem. 

(3) SOURCE - 

When the medium is of type "fluid", the source of medium 
(such as the fuel tank or the oil reservoir) is explicit 
specified, when energy type of medium is involved, the 
medium is always generated from the DRIVER, thus the SOURCE 
is the same as the DRIVER. 

(4) ENVIRONMEMT-OF-RESPONSE - 

Passive components which react to the driving tendency of 
the DRIVER are specified. The environment are based on the 
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flow organization of passive oomponents (i.e.i oasoaded or 
parallel). The sub-slob ’’parameter-definition'* links func- 
tional parameters of this environment to locations of its 
physical structure. Additionally, a sub-slob "boundary- 
conditions" interfaces the environment to its driver. A 
sub-slot called "applied-laws" refers to the set of physi- 
cal laws applicable to this environment. These laws provide 
parameters of this environment with proper interpretations. 

Having defined various aspects of a subsystem, we now show 
in figure 4 a subsystem frame which describes the fuel-subsystem 
in figure 3. 
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SUBSYSTEM-FRAME; 

# 

NAME; fuel-aubsystem 
MEDIUM; (fuel (la-a fluid)) 

DRIVER; (fuel-pump 

(enabled-when 

(fuel-pump running (> RPM 2400)) 

(fuel-tank not-empty (> quantity 0)) 

) 

) 

SOURCE; (fuel-tank 

(oapaoity 5000) 

(quantity (if-needed (sensor-reading Q))) 
ENVIRONMENT-OF-RESPONSE ; 

(passive-coaponents (LI filter L2 nozzle engine)) 
(path-structure (cascaded LI filter L2 nozzle engine)) 
(boundary-condition (connect fuel-pump LI)) 

( parameter-definition 

(flow- to fuel-pump LI (PI FI)) 

(flow- to LI filter (P2 F2)) 

(flow-to filter L2 (P3 F3)) 

(flow-to L2 nozzle (P4 F4)) 

(flow-to nozzle engine (P5 F5)) 

) 

(applied-laws ”fluld -dynamics") 


Figure 4. A frame representation for the fuel-subsystem. 


Subsystem P.ep.sndenslga. 

A subsystem grovips a set of component with a particular func- 
tional perspective. As a result, variables of the mechanism are 
partitioned accordingly. Two subsystems interact when they share 
same component(s) , l.e., at least one component is playing dual 


functional roles in both subsysteas. Thus a causal relationship 
can be Imposed among subsystems. If a component X is a passive 
member of envlronment-of-response in subsystem A also acts as the 
driver in another subsystem B, then we say that subsystem A 
’’drives" subsystem B, meaning that if both subsystems A and B are 
not working properly, It is likely that B's problem may be caused 
by A’s. This "driving-driven" relationship can bo further 
explained as following: Component X works as a passive member in 
the response environment of subsystem A, which because of the 
driving action in A "passes" or "receives" the medium flow of sub- 
system A, As a result, it enables X to work as the driver in sub- 
system B, which in turns cause the response in subsystem B. The 
set of variables associated with B is thus causally related to the 
set of variables associated with A. 

We again use the example in figure 3 to illustrate this 
point: Components "electrical source", "wire", and "fuel-pump" are 
grouped under "electrical subsystem", which models the electrical 
side of the mechanism. Voltage and current parameters are thus 
associated with electrical subsystem, which are governed by the 
laws of electricity. Similarly, "fuel-pump", "fuel-tank", "LI", 
"filter", "L2", "nozzle", and "engine" are grouped under fuel- 
subsystem, which applied laws of fluid-dynamics to describes the 
relationship among various fuel-flow parameters (P’s and F’s), In 
this mechanism, the fuel-pump plays dual functional roles in both 
subsystems. In electrical subsystem, it work as a passive load, 
which passively receives electrical flow. As the result, the 
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fuel-pump runs, which enables lb to act as the driver in the 
fuel-subsystem to cause fuel flows among passive components of the 
fuel subsystem, 

Xn a more oomplloated mechanism i the causal dependencies 
among lbs subsystems can be generally described as an WAND-OR” 
graph of subsystems. For example i figure 5 shows the subsystem 
dependencies of a DC-10 like airplane. With extensive "redundant” 
arrangement > the fuel-subsystem is driven by either of the electr- 
ical buses. The electrical subsystem in turn is driven by either 
engine, which also drives its corresponding oil-subsystem and 
hydraulic-subsystem. 

flanfiiualon 

( 1 ) Our functional , model provide two levels of functional 
description of a mechanism. At the component level, it treats 
each component as a functional unit which interacts with 

t 

other functional units via medium flows. At subsystem level, 
it describes causal dependencies among subsystems in terms of 
"driving-driven" relationships, which result in an "AND-OR" 
graph of subsystems. 

(2) Each subsystem takes a particular functional perspective to 
group components. Thus, variables of the mechanism are 
divided into meaningful functional groups at subsystem level. 

(3) Gausal-dependency relationships at subystem level are expli- 
citly specified which form the basis for fault isolation pro- 


cess. 
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Figure 5. Causal Dependencies among Subsystems of a DC-10 Airolane, 
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2i»Z* DAagnoatlci Jn£ar.fiHQ,s. 

In this section we discuss the inference strategy to heuristi- 
cally generate failure assertion using our flow model# The process 
of failure assertion is consisted of two sub-strategies, fault iso- 
lation and fault hypothesizatlon. We will discuss each process in 
detail in following sections. 

3..2.1# Fault Isolation 

The fault-isolation strategy uses subsystam causal dependen- 
cies relationships to heuristlcally isolate failure within a par- 
ticular subsysteis# 3ince meohanlsn} variables are partitioned -by 
subsystems, isolation of subsystem also means focusing on a par- 
ticular sot of variables. 

The isolation heuristics is derived from '’driving-driven” 
relationships of the functional model. The relationship says, if 
subsystem A drives subsystem B and symptoms are detected at both 

I 

subsystem, A is more likely to fail then B. A heuristical back- 
tracing strategy readily follows. When a deviated measurement is 
detected in a subsystem, we backtrace the causal-dependency link 
to look for possible symptoms in other subsystems. If another 
abnormal subsystem exists during the causal backtracing process, 
we will switch our focus on that subsystem. The process ends when 
we detect (1) a normally-functioning subsystem, or (2) a subsystem 
which does not drive by other subsystem. The result of causal 
backtracing process is a failure propagation trace of subsytems 
which describes the possible path of failure propagation. This 
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failure propagation trace will gul4@ the fault hypotheslzatlon 
process » which will be discuss In next section. 

Use the fuel-delivery mechanism is figure 3 as an example. 
If symptom is detected In the fuel subsystem > (P3 low) for exam- 
ple! the following isolation reasoning follows; 

(1) If fuel-pump is know to be running normally! l.e.! RPM > 
2400! the hypotheslzatlon strategy will be applied to fuel 
subsystem. 

(2) If the fuel-pump RPM is either below 2400 or unknown! the 
isolation strategy will backtrace and focus on the variables 
of electrical subsystem. 

In a general case as shown in figure 6! the isolation stra- 
tegy will enable us to associi^te symptom in subsystem A with symp- 
tom in subsystem D! thus avoid detailed analyses on less-likely 
subsystems B! C! E! F! and G. 

Fault Hyp o -thfislzation 

Based on the failure propagation trace resulted from the Iso- 
lation strategy! the hypotheslzatlon process focus on the most- 
likely faulty subsystem. The interpretation of variables in the 
subsystem is provided by the set of physical laws which governs 
the environment of response. For example, the symptom (V2 low) 
and (12 low) in figure 3 will lead to following fault assertions: 

Cl) (fuel-pump (resistance low)) 




O 
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Figure 6. Fault Isolation through Subsystem Causal-Dependencies. 



( 2 ) 


(wire (resistance high)) 


(3) (eleotrioal-souroe (voltage high)) 

These three hypotheses based on analyses of eleotrioal vari- 
ables will be verified by the constraint verification process 
which we developed previous. 

ii. Future. Plana Our research on the model-based diagnosis has thus 
far lead to the development of the functional model which provides the 
knowledge base for fault isolation and hypothesizatlon. Some other 
works are yet to be finished i which we will discuss below? 

(1) The detail syntax of the frame-like representation for subsystem 
is to be completed. 

(2) The isolation strategy is to be extended to take care of more 
complicated causal dependencies. A major challenge will be to 
detect and handle a ”dead-loop" situation. 

(3) Representation of physical law associated with the environment- 
of-response of each subsystem is to be developed. 

(4) The Interface between fault hypothesizatlon strategy and verifi- 
cation strategy is to be further studied. 
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Chapter IV 

UNDERSTANDING NOVEL MECHANISMS THROUGH 
INTENTION-DIRECTED RATIONALIZATION 


■ 1 * Introduction 

We are developing the principles and the architecture of a system 
which understands novel mechanisms through the process of purpose- 
directed rationalization. Given a novel instantiation, the system which 
understands the mechanism should be able to generate a consistent expla- 
nation of how the instantiation accomplishes its intended behavior, in 
conceptual vocabulary (jargon), in a framework of the intended operation 
of the mechanism, and at the appropriate level of detail. At the same 
time, the explanation must be complete in the sense that it accounts for 
all the abstract characteristics that define the abstract mechanism. It 
must also account for all the physical components that appear in the 
novel instantiation. 

This report is divided into two major parts. The first part is 
intended to put the concept of mechanism understanding in perspective. 
To this end, we discuss what we are doing and what the theoretical and 
practical advances are. The second part will focus on the architecture 
of the mechanism understanding system. We will Introduce a mechanism 
example, and explain each subsystem in the context of its actions on the 
example. We will focus on the processes and the knowledge sources which 
define each subsystem. 


Z* IteQhaniaa tfadaratandina 


Whafc la underatanding? The dictionary definition of ’underatand' 
la "to graap or oomprehf/nU the meaning Intended or expreaaed by 
another." In the meohanlam domain, the 'meaning Intended' la the 
dealgned behavior of the phyaloal Instantiation, and by a natural exten- 
sion, the 'another' In the definition la the meohanlam'a designer. 

There are two very important implications here on the content and 
orgsmlzatlon of the knowledge base of the understanding system. 
Firstly, the system and designer must share a common language (jargon) 
in order to communicate. This seed knowledge base common to both must 
include the domain's oonoeptual vocabulary (which transcends the indivi- 
dual Instantiations) as well as the domain's vocabulary of physical com- 
ponent models. Put In the context of the communication model, system 
and designer must 'talk the same language' In order for the system (as 
the listener) to understand the Instantiation (as the message) produced 
by the designer (as the speaker). 

Secondly, this system knowledge base should be organized into a 
library of Intenslonal definitions of mechanisms, In order for the 
rationalization to be an intelligently directed process. 

Z>1. Intfinslonal Jniera-taiidliig 

Consider the following scenario of understanding; 

Technician : "Look at this schematic diagram." 

"It is supposed to be a DC voltage amplifier." 
"Do you understand it?" 

; "yes, I do." 


System 


What did the system understand? This scenario is obviously incom- 
plete » Whatever the system understands is useless unless it oan be made 
available in some way (this is in the same vein as ’Write-Only Memory* ). 
In Artificial Intelligence work, the proof of understanding is often 
expressed as the explanations solicited in response to probing ques- 
tions. So the question sot which the understanding system oan deal with 
represents a good oharaoterization of what it understands. At this 
juncture, we would like to point out the versatility of the understand- 
ing the system is capable of. It oan handle question sets which are 
specific to various applications such as mechanism troubleshooting, 
mechanism design, and computer-aided mechanism learning. This will be 
expanded on in a later section, ’Application Advances'. 

How did the system understand? This is the second variable which 
is used to characterize the type of understanding that is achieved. One 
possible process of understanding is extensional understanding. By 
extensional understanding, we mean a process which is driven by an 
extensional \definition of the concept in question. The extensional 
definition of a concept is composed of the set of instantiations of the 
concept. If complete, the extensional definition is capable of very 
powerful performance. Put into the context of the mechanism domain, the 
extensional definition of the ’amplifier’ concept would be the set of 
all amplifier instantiations (and ’novel instantiation' would no longer 
have meaning) . It is clear that an understanding system based on exten- 
sional understanding is not elegant and may not be practical. 

A second possible process of understanding is intensional under- 
standing. By intensional understanding, we mean a process which is 
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driven by an inbensional definition of the conoept in question. The 
intensional definition of a oonoept is composed of the intrinsic proper- 
ties which characterizes the abstract concept. It transcends the 
instantiations and in fact specifies the essential qualities each must 
satisfy to be an instance. The Intensional definition is intrinsically 
complete. Put into the context of the mechanism domain^ the intensional 
definition of the 'amplifier’ oonoept would be composed of such abstract 
oharaoteristioa as 'gain' and 'DC bias', incorporated in a behavioral 
description of the definitive operation of amplifiers. Understanding a 
novel physical instantiation would then be an interpretational process 
of rationalizing how each abstract characteristic is achieved by the 
instantiation under study, in the operational context appropriate to 
that characteristic. Intensional understanding is conceptual, and 
therefore more intelligent. 

The key to understanding by intention-directed rationalization is 
the existence of intensional definitions in the mechanism domain. We 
will define the meta intensional definition (describing the types of 
knowledge that comprise the intensional definition) in a later section 
on 'Framework Establishment'. It is important to note here that the 
intensional definition provides global, concept-specific guidance to the 
understanding process. (To emphasize the key role that intrinsic pro- 
perties play in understanding by rationalization, we will use the term 
'intensional definition'; to emphasize the conceptual domain knowledge 
organization into intensional definitions of abstract mechanisms, we 
will use the term 'conceptual definition'; they should be taken to 
refer to the same definition.) Intensional understanding can be charac- 

K 



berized as dlreobed-analysla while exbenslonal understanding can be 
characterized as table-lookup* 

Z.*Z» JExplanatlQh .Chacaot, sciati c a 

Since the proof of understanding is in the explanation, the process 
of understanding can be viewed as filling in an explanation framework 
from which answers to directed questions can be drawn. .In that perspeo- 
blve, * depth* of the understanding is manifested as ’goodness* of the 
explanation. What characterizes a ’good* explanation? 

An explanation (understanding) must at least be consistent in the 
sense that it is plausible within constraints imposed by the novel phy- 
sical instantiation the system is trying to understand. The constraints 
are those imposed by the behavioral models of the physical components 
and those imposed by the connective scheme intrinsic bo the novel physi- 
cal instantiation. 

Z-Z-Z- .Rationalization 

In line with the idea of the intensional definition which captures 
the abstract mechanism, the explanation (understanding) is a rationali- 
zation of how the novel physical instantiation does achieve the abstract 
characteristics which define the abstract mechanism. It explains how 
the novel physical instantiation conforms to the conceptual definition 
by bridging the two representations through a causal link. The result 
is a component level explanation of mechanism level behavior. 


la itfliifijBat .VQQabularx 


The explanation (undoratanding) muat incorporate the conceptual 
vocabulary (4argon) that la the language of the domain. In being able 
to use the Jargon oorreotlyi the ayatem ia immediately credited with a 
high level of domain underataindlng. Alao> explanatlona should allow the 
questioner to focus hia attention on understanding the content of the 
explanation of the novel phyaioal lnatantlation» and not on perhaps 
unfamiliar terminology. Explanations in domain conceptual vocabulary 
minimize the language gap. Furthermore, the conceptual understanding la 
more immediately applicable in expert system applications. 

Qpepafclonal ConfcQKfc 

Since every mechanism is Intended to perform some operation, the 
explanation (understanding) must be housed in the definitive operational 
context of the abstract mechanism. This Includes such contextual 
knowledge as the intended input aignal, the Intended phase of operation, 
the Intended output signal, and the intended abstract characteristic 
highlighted in this phase. The operational context provides the per- 
spective for rationalizing how each abstract characteristic of the 
intensional definition is achieved by the novel phyaioal Instantiation. 

At. Approprlata. lifiyal Petall 

The explanation (understanding) should be organized at various lev- 
els of physical detail. This organization corresponds to the basic lim- 
itations of the Human Short Term Memory. If there are too many com- 
ponents to keep track of, the human becomes confused. Thus, the concept 
of the physical substructures (which are mechanisms in their own right) 
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J.S inbrlnalo to design and oust be accounted for by understanding. The 
explanation of a mechanism should be in terms of its physical substruc- 
tures (sub-meohanlsms). Each substructure is recursively a mechanism 
which has its own substructures (sub-mechanisms). The result is a con- 
ceptual explanation hierarchy of various levels of detail. In other 
words, the system should not explain a mechanism of several hundred com- 
ponents all in one breath. 

Aasounting. Xcr. .C,onaep.b,ual, JaXlnltlpn. 

The explanation (understanding) should be complete in the sense 
that it accounts for all parts of the intensional definition of the con- 
cept. In other words, the novel physical instantiation must satisfy all 
the Intensional properties of the abstract mechanism. 

Ao.oounb,lng X2211 N.oy.,al, Phyaiaal. In 8 .tan.tiatlQ.n. 

An underlying assumption made by the system is that the mechanism 
is well-designed. There are no components in the instantiation which do 
not serve In helping to accomplish some purpose. Correspondingly, the 
explanation (understanding) should be complete in the sense that it 
accounts for all components of the novel physical instantiation. 

Ihs.Q,gs.tlQaI Adyaacaa. 

Now that we have established WHAT we intend to do (Mechanism Under- 
standing), HOW we intend to do it (Intensional Understanding), and HOW 
we Intend to prove it works ('Good' Explanation), we will address the 
issue of V/HY we want to do it. This section covers the theoretical 
advances of mechanism understanding. The next section covers the 


ndvAiioes in experb syabta applioablono vhloh are enabled by aeohanisn 
understanding. 

Xnfceaaiflaal, Merjabanding. s£. JHayfil .EhyfliQal. JnataabAablQns. 

The understanding of novel insbanoea (be it plans or aoohanisms) 
under the oonoeptual guidanoe provided by intensional definitions is a 
oognitive process which is uniquely human. It forns the basis of his 
versatility and adaptability. The definition of a system which is capa- 
ble of understanding novel physical instantiations represents a very key 
step in understanding the general process of Understanding. 

JMmi Knfi,wJLg.dgfi. Leyeilfl. 

Surface level knowledge (or the Instantiation Level) is nob auffi- 
dent to drive a system which understands novel physical instantiations. 
Accordingly, we have defined a second knowledge level (or the Abstract 
Mechanism Level) of Intensional definitions of mechanism concepts. The 
intensional definition transcends the physical instantiations of the 
defined concept. (What comprises an Intensional definition is a key 
Knowledge Organization issue which we will elaborate on in the section 
on 'Framework Establishment'.) 

£flnoep.buaI F.o.ous, Aa Aba, tract, .Viewp.Q.ln.ta. 

Focus is a key result in Goal-Subgoallng (the decomposition of a 
problem into several smaller subproblems which may be continued recur- 
sively). The issue is how to decompose the problem. We define a 
viewpoint as one abstract characteristic and the operational context in 
which to analyze it. By placing the novel physical instantiation into 


this viewpoint, the intenslonal definition oonqeptually directs the sys- 
tem to foous on one Intenslonal property at a time. Thus^ the under- 
standing (goal) proceeds, one characterlstlo (subgoal) at a time, In the 
appropriate viewpoint. ‘‘ 

fifljuagnfiJit.-ffieQhanlam fllfir.ar.aliY. 

There is a focusing process in the physical plane as well as the 
conceptual plane. This is manifested as the Component-mechanism Hierar- 
chy in which each physical structure is regarded on the one hand as a 
mechanism composed of its son nodes, and on the other hand as one com- 
ponent of its father node. The conceptual focus and the physical foous 
are the basis of explaining the novel physical instantiation in the 
right context and at the appropriate level of detail. 

gonceptuai flxplanafciflti fllfirariihy In. .Jargon 

The generated conceptual explanation is a hierarchical structure 
which is characterized above in the section on ’Explanation Characteris- 
tics'. Explaining in the right context and at the appropriate level of 
detail is recognized as a key problem in man-machine interfacing (as 
indicated by its emphasis in the Stanford production systems such as 
MYCIN [1]). 

flklil. flaowl.edg.fi. ,lBas.e. 

The understood physical instantiations can be organized into a 
knowledge base we call the Skill Knowledge Base. The Skill Knowledge 
Base drives the expert system applications, which we will elaborate upon 
in the following section. From the standpoint of each application, the 


oomblnatlon of the understanding system and the Skill Knowledge Base 
forms a self-extending system. For each novel physical Instantiation 
which the application will act on, the understanding system can extend 
the Skill Knowledge Base to li:olude It. The Issue of knowledge base 
consistency for the Skill Knowledge Base Is really the Issue of con- 
sistency of the Intenslonal definitions which drive the understanding 
system. This Is desirable since there are fewer Intenslonal definitions 
and they are relatively well-defined. 

ABBllsa.t.iaa Advanoea 

« 

A system which understands novel physical instantiations can sup- 
port various expert systems in specific applications by providing its 
understood instantiations as a Skill Knowledge Base. This Skill 
Knowledge Base act^ as the consultant to the application system which is 
itself probably acting as a consultant [Figure 1]. The medium of 
exchange is the application-specific question set for which the Skill 
Knowledge Base will provide solicited answers. Seen in this context, 
the understanding system can be viewed as a deeper knowledge base into 
which various application systems can be plugged. We will expand on 
three potential applications on which an understanding system has great 
impact. They are by no means an exhaustive applications list. 

^•1.1. Computer-aided LSATning 

An immediately appropriate application of an understanding system 
is computer-aided learning. This is in contrast to computer-aided 
instruction in which pre-programmed, static lessons are projected on the 
CRT screen in fixed order. There is very little student input simply 
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because the program 1/3 not Intelligent enough to handle any deviations 
from its planned lessons. New lessons must be tediously programmed by 
hand. In effect the computer-aided instruction system learns by being 
programmed. It certainly cannot handle novel designs which the student 
might have seen in the textbook, but which do not appear as a selected 
example in the pre-programmed lessons. 

With the system which understands novel physical instantiations, 
the student has a dynamic system which can understand the novel design 
and explain it to him in conceptual vocabulary. The explanation is con- 
sistent, complete, and at an appropriate level of detail from the sub- 
structure level to the primitive component level. In this way, it 
caters to various levels of students automatically. 

The computer-aided learning system is self-extending since each 
novel physical instantiation represents another lesson added to the 
Skill Knowledge Base. It can draw upon this knowledge base in response 
to new student requests to explore abstract mechanisms further. In 
effect, the student who first raises a novel physical instantiation has 
taught the understanding system which in turn teaches other students. 
The computer-aided learning system learns by rationalization. It 
automatically learns to teach automatically. 

J2..1.2* Computer-aided. Pesign 

With a Skill Knowledge Base (design library) to draw from, the 
computer-aided design system can propose a basic design in response to 
performance specifications desired by the designer. Furthermore, with a 
complete intensional definition, the system is able to Intelligently 


elicit design decisions, in conceptual designer language, which the 
designer might have overlooked. For example, onoe a designer specifies 
that he wants an amplifier, the system might inform him that he must 
specify whether it is to be a voltage amplifier or power amplifier. 
Since the Skill Knowledge Base includes the causal bridge between the 
abstract definition and the physical instantiation, the performance 
specifications can be causally baoktraced to what component parameter 
values should be changed, and to what new values. In this way, the 
computer-aided design system can act as an apprentice designer. 

In another context, the computer-aided design system can act as 
monitor. Novel physical designs can be submitted to the system >f)tiich 
tries to understand it under the direction of the Inbensional definition 
which any design must satisfy. Design errors can be caught if a con- 
sistent explanation of an abstract characteristic cannot be reached. 
The inconsistent explanation can be offered as partial information to 
help clear up the error, rather than just stating that something is 
wrong. Design oversights can also be caught since the intensional 
definition serves as a conceptual checklist of intrinsic design con- 
siderations. Again, as above, novel designs which pass the tests are 
incorporated into the Skill Knowledge Base, perhaps to be suggested as a 
basic design later on down the line. 

Troubleshooting 

Intelligent troubleshooting must proceed from an understanding of 
the mechanism under study. This understanding comes in two parts; the 
intensional definition of the abstract mechanism, and the rationalized 
novel physical instantiation. Each part plays a role in intelligent 


troubleshooting. 


The Intenslonal definition contains knowledge of the abatraot 
charaoterlstlos which define the mechanismi and the intended operational 
context of the mechanism. These serve to define the functional test 
procedure I which appropriately should be synthesized at the abstract 
mechanism level. What the intenslonal definition provides the troub- 
leshooting system is knowledge of WHAT to look for in the output 
(abstract characteristic) and the CONTEXT in which to look (operational 
context). Since there are multiple viewpoints which decompose the 
abstract mechanism into multiple abstract characteristics, there is 
correspondingly one funGtional test specified per viewpoint. By combin- 
ing these functional tests into the test procedure and executing the 
teat procedure, some of the abstract characteristics will be discovered 
to be in error while others are still as they should be. Thus, the 
intenslonal definition drives the troubleshooting system to identify the 
fault signature in terms of the abstract characteristics which define 
the abstract mechanism. This corresponds to the test procedure followed 
by the human troubleshooter. 

The rationalized novel physical instantiation contains knowledge of 
how each abstract characteristic is achieved by a substructure of the 
instantiation under study. From these links of physical substructures 
to abstract characteristics, and the two seta of 'good' and 'bad' 
abstract characteristics determined by functional testing, the identity 
of the component causing the fault can be localized in the following 
way. Initially the troubleshooting system assumes that every component 
is in the candidate set of faulty components. For every abstract 
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oharaofceriatio that was determined to be ’good’ in the functional test- 
ing phase, the system assumes that the corresponding physical substruc- 
ture is ’good'. This is certainly a heuristic but a very reasonable 
one, although it is possible that two components in a 'good' structure 
may be faulted in a complementary manner to mask eddh other. If we make 
the single fault assumption, then it is no longer a heuristic, but 
rather is always true. By applying this heuristic, the components in 
all the 'good' substructures are removed from the candidate set of 
faulty components. A second heuristic can be applied at this, point - 
the faulty behavior should be explainable be the smallest set of bad 
components possible. In most cases, there should be only one faulty 
component. It therefore seems reasonable to order the candidates 
remaining in the candidate set by the number of 'bad' abstract charac- 
teristics in which they play a role (appear in the corresponding physi- 
cal substructure). Those components which appear in every 'bad' physi- 
cal substructure should certainly be checked first. If we make the sin- 
gle fav)ilt assumption, then only those candidate components which appear 
in every 'bad' physical substructure are kept in the candidate set. All 
other components are inferred to be good. 

In the case of parameter drift faults (the component parameter 
drifts high or drifts low), there is yet another type of information 
provided by the rationalized novel physical instantiation. The abstract 
characteristics are related to a corresponding physical substructure. 
But the system eilso has the equational relationship between the abstract 
characteristic and the parameters of the components in that physical 
substructure. By hypothesizing a particular candidate component (in the 
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partial order determined above), the troubleshooting system oan deter- 
mine how that oomponent must have faulted (direction of parameter drift) 
to cause the faulty behavior, by using the equational relationship. If 
a parameter of a candidate component is determined to have drifted high 
in one substructure (to explain one faulty abstract characteristic) but 
low in another, it is reasonable to question whether the oomponent is 
the culprit. Again this is a heuristic since more than one oomponent 
may be faulty. If we make the single fault assumption, then that candi- 
date described above is inferred bo be good. 

Troubleshooting is a very difficult application which has recently 
attracted growing interest (all these comments are applicable to 
computer-aided instruction and computer-aided design) . We do not 
presume to denigrate its difficulty. Building the knowledge base of 
troubleshooting techniques is undoubtedly a complex problem in both 
knowledge organization and knowledge representation. However, we do 
claim that an understanding system would play a key role in facilitating 
the concept of functional testing, which has recently been the focus of 
state of the art research [2, 3]. We have presented a first cut indica- 
tion of how an understanding system would play that role. 

3.. Focusing i2n ±hs. System 

3.1. Mechanism Understanding System 

The input to the mechanism understanding system is composed of two 
parts. The primary input is a description of the novel physical instan- 

a 

blation containing such information as component names, component types, 
and the connection schemes which define the physical structure. The 


aeoondary input is the maohanism name whioh identifies the intended pur- 
pose of the novel physical instantiation. The output is proof of oon- 
oeptual understanding of the novel physical instantiation. That proof 
is manifested as a hierarchical explanation of how the physical struc- 
ture achieves the abstract charaoterisblos which make up the intensional 
definition referenced be the mechanism name. The hierarchical explana- 
tion is in conceptual vocabulary, housed in the Intended operational 
context, and complete in accounting for the intensional definition and 
the novel physical instantiation [Figure 2]. 

The same mechanism name may apply to several different novel physi- 
cal instantiations. For example, there are various physical instantia- 
tions of the DC voltage amplifier [Figure 3]. This is the power of 
intensional understanding. The abstract mechanism of DC voltage amplif- 
ier transcends its various physical Instantiations, including some that 
may have not yet been designed. The understanding system knows what 
intrinsic properties any design, old or new, must satisfy to legiti- 
mately be called a DC voltage amplifier. So the understanding system 
knows what to look for, and in what operational context, in rationaliz- 
ing whether a novel physical instantiation can legitimately be called a 
DC voltage amplifier or not. 

The understanding system is composed of four processes [Figure ^]; 
Framework Establishment, Physical Conceptualization, Behavior Verifica- 
tion, and Experience Incorporation. 

Framework Establishment is the process of placing the novel physi- 
cal instantiation into various viewpoints (one abstract characteristic 
and the operational context in which to analyze it). What is happening 
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Is that the intenslonal definition conoeptually guides the understanding 
system to foous on the novel physical Instantiation* one intrlnslo pro- 
perty at a time. 

Physical Conceptualization is the process of moving the structural 
description as far up the Component-mechanism Hierarchy (see section on 
Theoretical Advances) as allowed by experience. The experience is the 
collection of understood physical Instantiations which form the Skill 
Knowledge Base. Here again* the attention of the understanding system 
is being focused, this time conceptually guided by experience gained 
through past encounters with other novel physical instantiations. The 
result is still a atructurai description, bub with fewer components in a 
simpler connection scheme. 

Behavior Verification bakes this simpler structural description, in 
its various viewpoints, and generates the component- to-meohanism link. 
That link explains how the physical structure achieves the abstract 
characteristic focused on, in the appropriate context, in that 
viewpoint. 

Experience Incorporation is the process of inserting the understood 
novel physical instantiation into the Skill Knowledge Base. One primary 
task is to make the experience gained in this session available for 
application in the Physical Conceptualization process in future ses- 
sions. Another is to coordinate the hierarchical explanation of the 
novel physical instantiation and make it available stand-alone, or in 
the context of one of the various applications an understanding system 
can support. 


In the next four seotdono, wo will delve into the four proqeaaea 
that oompriae the underatanding ayatem* We will fooua on the knowledge 
aouroea whioh drive then and ahow the key anapahota of the data baae aa 
it paaaes through the underatanding ayatem. To oonplenent the explana- 
tion of the workinga of the varioua prooeaaea, one exanple will be 
rationalized. To aerye that purpoae, we will uae the tranairten inatan- 
tlation of the DC voltage amplifier [Figure 3]» 

a.Z. framework Sa-tabliahnent 

The key knowledge aource of the Framework Eatabliahnent prooeaa is 
the oonoeptual definition whioh is intensional in nature. The purpose 
of Framework Establishment is to place the novel physical instantiation 
into various viewpoints aa dictated by the conceptual definition 
corresponding to the mechanism name provided as input. In this way, the 
conceptual definition breaks the problem of understanding down into 
various subproblems of understanding how a particular abstract charac- 
teristic is achieved by the novel physical instantiation. The result is 
conceptually-directed focus of analysis, one viewpoint at a time, by the 
understanding system. 

The meta conceptual definition (describing the types of knowledge 
that comprise the conceptual definition) has two basic types of concep- 
tual knowledge [Figure 5]. The first is a list of abstract characteris- 
tics. The second is a state transition diagram capturing abstract 
mechanism behavior. To explain the contents of the conceptual defini- 
tion, we will use the one corresponding to the DC voltage amplifier. 
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The list of abstract characteristics, a list of jargon specific to 
the amplifier [Figure 6], is a vocabulary list of intrinsic properties 
which transcend any physical instantiation. Such conceptual vocabulary 
as ’bias’ and ’gain’ are performance characteristics which describe 
definitive behavior. Such conceptual vocabulary as ’class of opera- 
tion', ’signal type’, and ’frequency range' are olassificational charac- 
teristics which partition the set of amplifiers in the pragmatic taxon- 
omy intrinsic bo the domain. Associated with each abstract characteris- 
tic is a constraint description. For example, the bias must be a DC 
value and the ge^in must be a numerical constant. The class of operation 
can be labelled in four possible ways (A, B, AB, or C) each of which is 
well-defined. The signal type can be labelled in two possible ways, and 
so on. This list represents the static vocabulary used by those ini- 
tiated into the domain. There is nob yet any direct knowledge of opera- 
tion. 

The state transition diagram which is intended to capture the 
abstract mechanism behavior [Figure ?]» is a directed graph with two 
types of nodes, state nodes (indicated by ’S:’) and action nodes (indi- 
cated by ’A:'). Eai?h state node represents a viewpoint in which one 
abstract characteristic of the conceptual definition should be deter- 
mined. The action-state sequence leading up to the state in question 
represents the establishment of the proper- operational context in which 
to do the analysis. In the 'bias’ state, the system is directed to 
analyze how the novel physical instantiation achieves the bias. The 
operational context indicates that the power is on, but that there is no 
input signal. This state transition diagram is not intended to define 
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the only way in which the mechanism may operate. Rather, it is one way 
which puts the mechanism through its paces thoroughly. It serves as an 
anchor for directed analysis. The state transition diagram represents 
the intensional knowledge of the dynamic (procedural) aspects of the 
abstract mechanism. 

The conceptual definition provides the system with knowledge of 
what to look for and in what context to look. It does so through a 
aeries of viewpoints. The meta viewpoint [Figure 8] holds four basic 
types of knowledge. The abstract characteristic tells the understanding 
system what to focus on in this viewpoint. The context contains the 
history (action-state Sequence leading up to the state corresponding to 
the current viewpoint), the proper input signal, and the expected output 
signal. The focused physical structure ignores physical components 
which are not relevant to this viewpoint. The component-level rational- 
ization is a placeholder for the component-level explanation of how the 
novel physical instantiation achieves the abstract characteristic. The 
focused physical structure will be tailored to reflect this explanation. 
The viewpoints corresponding to 'bias' and 'gain' for the DC voltage 
amplifier are shown in Figure 9. 

The output of the Framework Establishment process is a set of 
viewpoints, which are passed to the Physical Conceptualization process. 
Framework Establishment has conceptually decomposed the understanding 
problem by defining the intensional set of understanding subproblems for 
the rest of the understanding system to focus on. 
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Viewpoints - DC Voltage Amplifier 
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1 , 1 . Piiyaioal .ConaaBtuallzation 


The key knowledge source of the Physical Conceptualization process 
is the Semantic Template Hierarchy which represents the accumulation of 
experience from past sessions with other novel physical instantiations. 
It resides in the Skill Knowledge Base. The purpose of Physical Concep- 
tualization is to move the structural description of the novel physical 
instantiation as far up the Component-mechanism Hierarchy as allowed by 
the Semantic Template Hierarchy. In this way> the Semantic Template 
Hierarchy simplifies the problem of understanding by simplifying the 
structural description of the novel physical instantiation. The result 
is conoeptually-directed focus of analysis * at the highest level of 
structural description possible, by the understanding system. 

The meta Semantic Template has three types of knowledge [Figure 
10]. The first is a structural pattern of several physical components 
connected in a predefined connection scheme. The second is a list of 
semantic constraints which the structural pattern must satisfy. The 
third is a behavioral description of the structural pattern considered 
as a single, new component (actually a pointer to the conceptual defini- 
tion for which this semantic template is one physical instantiation) . 
The Semantic Template can be regarded as a transformational operator 
which looks to perform syntactic matching and semantic matching against 
the novel physical instantiation. If both types of match constraints 
are satisfied, the Semantic Template transforms the pattern in the novel 
physical instantiation into the one single new component. The result is 
a new level in the Component-mechanism Hierarchy corresponding to this 
instantiation. The base level of the hierarchy is the initial struc- 
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turaX description of the novel physical instantiation. Note that it 
doesn't matter how many primitive components comprise the structural 
pattern, once it is transformed by the Semantic Template into a single 
new component. This is the power of the Component-mechanism H Hierar- 
chy. The new component has its abstract characteristics just as did 
each primitive component. The Semantic Template transformation simpli- 
fies the syntactic description without losing any semantic knowledge. 

The structural pattern is the basis of the syntactic matching. 
This process is classical in the field of pattern matching and will not 
be discussed here. 

The list of semantio constraints which the structural pattern must 
satisfy is the basis of semantic matching. The power of coordinating 
knowledge-based semantic matching with syntactic pattern matching also 
comes from the seed knowledge base of intensional definitions which is 
the heart of the understanding system. Each leaf Semantic Template is 
associated with the abstract mechanism for which it is one possible phy- 
sical instantiation. Each new leaf Semantic Template therefore 
represents at least one previous session through the understanding sys- 
tem. The semantic constraints are generated from these previous 
interactions by an induction process which will be explained in greater 
detail in the section on Experience Incorporation. 

One type of semantic constraints is the parameter relationships 
among the components in the structural pattern. For example, in the 
operational amplifier instantiation of the DC voltage amplifier [Figure 
3], the drift resistor 'Rd' should have the same impedance value as that 
seen by the inverting input of the operational amplifier in order for 


*Rd’ to be aobing as a drift resistor. Another type of lemahtio con- 
straint is the voltage-ourrenb boundary conditions which must be met for 
the structural pattern to behave as intended. For example, in the 
transistor instantiation of the DC voltage amplifier [Figure 3], the tap 
current of the voltage divider (R1 and R2) must be approximately zero 
for the physical structure to be acting as a voltage divider. The olass 
of semantic constraints represents the physical context (of neighboring 
structures) that the structure in question must have in order to prop- 
erly operate. The Semantic Template corresponding to the voltage 
divider which appears in our vehicle example is shown in Figure 11 and 
the result of matching in the bias viewpoint of the DC voltage amplifier 
is shown in Figure 12, The result of matching is structurally simpler 
bul conceptually still the same. 

Now that we know that the system will use Semantic Templates, the 
obvious question is how does the system know where oh the novel physical 
instantiation to begin matching? It knows where because it uses the 
concept of anchor points, and the process of anchor point propagation. 
Anchor points represent physical boundary points where meaningful struc- 
tures must begin and end. Clearly, the initial set of anchor points 
contains the input node, output node, Voo node, and GND node. Semantic 
Template matching begins at anchor points. As structures are matched 
and transformed by Semantic Templates, the new boundary points identi- 
fied by the match are entered into the set of anchor points, and thus 
anchor point propagation. In the DC voltage amplifier [Figure 12], the 
matching of the voltage divider identifies the transistor base node as a 
new anchor point. 
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Onoe we know where on the novel physloal Instantiation the system 
begins Semantic Template matching, the next question is how does the 
system know which Semantic Templates are most likely to succeed in 
matching and should therefore be tried first? Some heuristic guidance 
is provided by the Semantic Template Hierarchy [Figure 13]* The organi- 
zation of this structure is based on the pragmatic domain tendency to 
classify mechanisms physically by key components • In the circuit 
domain, these are suoh active elements as transistors and operational 
amplifiers (we speak of the ’family of operational amplifier circuits’ 
and the 'family of gas-engine-powered vehicles’). Thus the organization 
of the Semantic Template Hierarchy is a set of physloal classification 
trees that comprehensively part tlon circuit families. Each succeeding 
level of the hierarchy represents physical specialization (the hierarchy 
is a generalization-specialization tree). Thus if the operational 
amplifier is a component in the novel physical instantiation, the under- 
standing system begins traversal down the operational amplifier circuit 
family tree which can be viewed as a decision tree. We do not claim 
that this is the only possible organization, but only that it has 
credence as a common, efficient pragmatic organization. 

The output of the Physical Conceptualization process are simplified 
physical structures each within its proper viewpoint, which are passed 
to the Behavior Verification process. Physical Conceptualization has, 
under Conceptual guidance from past experience, simplified each under- 
standing subproblem for the rest of the understanding system to focus 


on. 
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The key knowledge source of the Behavior Verification process is 
the constraint models of components and connections which must be satis- 
fied in order for the behavior to be consistent. Ambiguities arise in 
that the constraint models may allow more than one consistent explana- 
tion of possible behavior. This occurs because the novel physical 
instantiation is a context-free mechanism unless knowledge of designer 
intentions are somehow made known to the understanding system. In the 
scenario of understanding presented by intention-directed rationaliza- 
tion, this knowledge is made available in the intensional definitions 
which comprise a seed knowledge base of the understanding system. Thus, 
Behavior Verification is conceptually guided to work within viewpoints 
defined by Framework Establishment. The purpose of Behavior Verifica- 
tion is to automatically generate a component level explanation of how 
the novel physical inst.' 4 itiation achieves the abstract characteristic 
specific to the viewpoint, in the operational context specific to the 
viewpoint. One way in which it can do this is the process of constraint 
pro.pagation [4]. By doing so, the understanding system creates a causal 
link between the abstract mechanism and the components of the novel phy- 
sical instantiation. The result is an equational relationship between 
the abstract mechanism characteristic and abstract component charac- 
teristics of its corresponding substructure. 

The component constraint model is generated deterministically from 
the component behavior model [Figure 143, which is the corresponding 
intensional definition of the component as an abstract mechanism (primi- 
tive components are leaf nodes in the Component-mechanism Hierarchy) . 
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In other* words » eaoh component in the physical structura passed from the 
Physical Conceptualization process has a corresponding constraint knodel 
baaed on it^i abstract behavior. For example, the resistor Is a primi- 
tive component which behaves as specified by Ohm’s Law [Figure 153. Its 
constraint model or subgraph Is composed of the three variables In the 
equation and the three corresponding demons [5] which monitor the data 
base. Simply stated, the demon is activated When all but one of the 
variables are Instantiated (take on values) In the data base. It uses 
the behavioral description to determine the value of the last variable 
which it then enters Into the data base, hopefully triggering other 
demons. The voltage divider, while hot a primitive component, is still 
a component. It oorrespondingly has a behavioral description in terms 
of key variables Just as did the resistor. It therefore also has a con- 
straint subgraph [Figure 153. 

The constraint network is the connection of the component con- 
straint subgraphs according to the connection scheme intrinsic to the 
novel physical instantiation. It is generated deterministically from 
the physical structure in eaoh viewpoint as focused by the Framework 
Establishment and Physical Conceptualization processes. One type of 
connecting ’glue' is the connection constraint specified by Klrohoff’s 
conservation laws. For example, for the bias viewpoint of the DC vol- 
tage amplifier [Figure 16], the current coming out of the emitter resis- 
tor, Re, must be the current going into the emitter terminal of the 
transistor, Q, as specified by KCL, Another type of connecting ’glue' 
is the connection of oomponent terminals to a common node. For example, 
the output terminal of the voltage divider, V-div, shares the same node 
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aa the baae terminal of the tranalstor, Q, so the output voltage of the 
voltage divider is identically the base voltage of the transistor. Any' 
explanation whloh is generated from this constraint network must be con- 
sistent. 

The constraint propagation process begins with the insertion of 
known variables into the data basoi whloh is being monitored by the 
demons associated with each comporient whose subgraph is a part of the 
constraint network. In the case of the DC voltage amplifier, the expla- 
nation which is generated is an equational derivation [Figure 17] which 
can be viewed as a mathematical proof from hypothesis (* given the physli* 
oai afcruQfcure and the context to conclusion ('then the output is 
Indeed the abstract characteristic in question ...'). The result is an 
equational relationship between the abstract mechanism characteristic 
and the abstract component characteristics of the pertinent physical 
structure. 

It is appropriate here to discuss the challenging and inquisitive 
nature Inherent in an understanding system. Because of the accountabil- 
ity requirement for explaining all of the intensional properties of the 
conceptual definition, the understanding system is able to challenge 
what it perceives to be an Incomplete novel physical instantiation, if 
it can verify that an abstract characteristic is not achieved. For 
example, in explaining the bias of an amplifier, the equational rela- 
tionship should satisfy the intensional constraint that the bias is a DC 
value. If not, the understanding system knows that the novel physical 
instantiation should not be called an amplifier and can back up its 
challenge. Because of the accountability requirement for incorporating 
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all the oomponenfca of tha novel phyiloal inabantiaWon, the underaband- 

ing ayatem la able bo know when ita knowledge base la lnooDj.r;)lete, if 

» 

some oomponenba do nob appear In any viewpoint explanation. It oan 
inquire about the miaaing oonoepb aid baok up the question by refereno- 
Ing the unused oomponenba. It also knows what questions to ask based on 
the meta-level knowledge [6;‘ It has defining its knowledge aouroes. 
Furthermore! once a now oonoepb is actively solioibed» the understanding 
system can teat the oompletenes/]i and oorreotness of its understanding by 
trying to rationalize the concept on the novel physloal instantiation 
which inspired the system's curiosity! much as a human student would. 

The output of the Behavior Verification process is the set of com- 
pleted viewpoints which each explain one abstract characteristic 

causally In terms of the physical structure which achieves it. The col- 
lection of viewpoints, which comprise the understood mechanism, is 
passed bo the Experience Incorporation process. Behavior Verification 
has explained the novel physical instantiation in terms of its under- 
stood physical substructures. 

1.^. Experience Incorporation 

The Experience Incorporation process has several responsibilities. 
It must coordinate the set of viewpoint explanations into a form suit- 
able to respond to directed questions, either stand-alone or from vari- 
ous application expert systems. Since the viewpoint is the basis from 
which the understanding system focused its understanding efforts, the 
viewpoint is also the basis of focused explanation. Since the relation- 
ship among nodes of the Component-mechanism Hierarchy is one where the 
father node is explainable in terms of its son nodes (the collection of 




son nodes .In its oonneotion scheme is an instantiation of the abstradt 
father node), the explanation of tho novel physical instantiation can 
take place at various levels of r?'?'noeptual detail CPigure 183. For 
example, the understanding system oan explain the DC voltage amplifier 
in terms of the bias and gain; it oan explain the bias viewpoint of the 
DC voltage amplifier using the voltage divider as a component; it oan 
explain the factor viewpoint of the voltage divider using the resistors 
R1 and RS as components; it can explain the bias viewpoint of the DC 
voltage amplifier using the resistors R1 and R2 as components. The 
level of explanation should proceed from the highest level of the expla- 
nation hierarchy and filter down if concepts such as voltage divider are 
not familiar to the questioner. This is the power of a conceptual 
explanation hierarchy, as opposed to the myopic, static, single level 
explanation offered by production systems such as MYCINClJ. 

Another responsibility of the Experience Incorporation is the pro- 
cess of self-extension by properly hooking the understood physical 
instantiation into the Skill Knowledge Base and propagating the effects 
of the experience it represents. Specifically, this means the effects 
of applying the induction paradigm [7» 8, 93 to perturb the Semantic 
Template Hierarchy. In viewing the understood instantiation as a j'posi- 
tive example of the physical concept which is embodied In a Semantic 
Template, the induction paradigm directs a perturbation of the charac- 
terization of the physical concept to include the novel physical instan- 
tiation. 

The effect of properl.y hooking the understood physical instantia- 
tion and applying the induction paradigm on the Semantic Template 
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Hierarchy Is to the Skill Knowledge Base or experienoe. The 
understanding system matures as it is exposed to more and more novel 
physical instantiations, leading to Skill Knowledge Base growth « The 
greater experienoe is reflected in the Physical Conceptualization phase 
of understanding I where novel physical Instantiations encountered in 
future sessions are much more slwplifiablc. More complex substructures 
can be composed and viewed as single components because they have been 
encountered in the understanding system’s past experienoe. 

The accumulation of experienoe brings up a key point. The under- 
standing system can be viewed as a learning system to the extent that it 
learns novel physical instantiations which it hooks into its Skill 
Knowledge Base. The learning it performs is by conceptually directed 
analysis. The learning it performs is supervised [10] In the sense that 
all the novel physical instantiations are well-designed, named mechan- 
isms. In lino with supervised learning, it seems reasonable to regard 
the exercising of the understanding system as a continuous training 
sequence. The complexity of the novel physical instantiations should 
initially be fairly simple and grow increasingly more complex at a 
moderate pace. For example, before exercising the system with the DC 
voltage amplifier which includes a voltage divider, the system should be 
exposed to several voltage amplifiers from which it can progressively 
refine the corresponding Semantic Template. It can then expediently 
recognize the voltage amplifier in the Physical Conceptualization phase 
of rationalizing the DC voltage amplifier. 
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